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[57] ABSTRACT 

A computerized, electronic purchase mediating system 
includes a purchaser database having a list of purchasers and 
a merchant database having a list of merchants. The pu r- 
chaser database stores information about each purchaser 
— mcluding-a-set-ofT>e]^o_ni^^ 

-ch aser""cou Td use to purchase goodsH ^Wol^services. 
SimilarlyTthe merchant database T stor^intormafion^abTnit 
each merchant including a set of accepted payment methods 
that "the merchant" would accept for sale of the goods and/or 
services. The purchase system also includes a processor 
coupled to the purchaser and merchant databases. The 
processor receives a purchase request and accesses the 
merchant database according to a merchant identified in the 
purchase request to retrieve the set of accepted payment 
methods which corresponds to that merchant. The processor 
also accesses the purchaser database to retrieve the set of 
persona] payment methods which corresponds to the iden- 
tified purchaser. The processor then computes an intersec- 
tion of these two sets to derive a common set of any 
available payment method that is both accepted by the 
merchant and can be used by the purchaser for purchase of 
the goods and/or services. The purchaser is presented with 
the purchase amount and the common set of available 
payment methods to choose a most preferred form of 
payment. Upon selection, the processor consummates the 
sale and signs a digital signature with the purchaser's 
permission via password verification to ensure for the mer- 
chant that a completed transaction has occurred. 

55 Claims, 7 Drawing Sheets 
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COMPUTERIZED PURCHASING SYSTEM chaser and merchant are face-to-face, to a remote purchase 

AND METHOD FOR MEDIATING context, where the merchant and purchaser are separated 

PURCHASE TRANSACTIONS OVER AN from one another. For example, consider another familiar 

INTERACTIVE NETWORK transaction where a purchaser wants to buy a new lamp from 

TcruvirAi trier n 5 a mail order catalog. The purchaser places an order for the 

TECHNICAL FIELD j amp Qver tfae te i cp h one or through the mail. The purchaser 

This invention relates to computerized purchase systems might use a credit card, enclose a check, or simply wait to 

and methods for electronically transacting a purchase of be billed at the end of the month. The merchant takes an 

goods and/or services between a purchaser and a merchant. assumed risk that the ordering consumer is legitimate and 

The invention further relates to such purchase systems and io that payment will be forthcoming, and based upon that 

methods for facilitating purchase transactions over an inter- assumption, ships the new lamp to the purchaser, 

active network, and particularly, in an interactive television Ia thcsc ^5^0^ the merchant accepts a fairly high 

system. risk of not being paid (compared to other types of sales 

BACKGROUND OF THE INVENTION transactions) because the purchaser does not present a credit 

Tt r .1. u c a At 15 card or sign a credit card receipt. The purchaser can deny 

In a transaction for the purchase of goods and/or services, L . . K , . t . 

, u . * • n u *u u r* * . *»™^ that the transaction ever occurred, leaving the merchant with 

the purchaser typically has the ability to pay for the items * . . _ ' • f 1 1 ^ 

. c A te * * *u a T7 the burden of proving that a transaction took place. To meet 

using any one of many different payment methods. For Y 6 . * n , - L 

mstance/coiisiderthefammarsimadonwhereapurchaserin to K burdeD : the merchant typically tries to show that the 

a department store wishes to buy an article of clothing. The 20 P urchaser sl S ned for Tec ^ 1 of the P roduct * 

purchaser can pay for the clothing article with cash or by 1° recent vears > has been a dramatic growth in the 

check. Alternatively, the purchaser might wish to use a credit number of consumers that order goods and/or services, and 

card or a debit card. Indeed, it is not uncommon for the then pay for them, using electronic devices. For instance, it 

purchaser to carry many payment options in the form of & fairl y common for a purchaser to watch a home shopping 

cash, a checkbook, a bank debit card, as well as many television program, choose a product, and order the product 

different kinds of credit cards, including cards issued by the over to telephone. The product is shipped and the purchaser 

merchants themselves (e.g., a Sears® charge card or a >s billed at a later time. As another example, the viewer may 

Nordstroms® charge card), bank issued credit cards (e.g., a purchase a special movie or event that is scheduled to be 

SeaFirst Bank VISA® credit card or a Bank of America shown at a particular time, like that of the Pay-Per-View® 

MasterCard® credit card), an organization-related credit arrangement. In this situation, the viewer orders the special 

card (e.g., United Airlines Mileage Plus First Card™ or an program from the cable company over the telephone, typi- 

IEEE credit card), and association credit cards (e.g., Dis- call y usin g aa automated menu, and the program is elec- 

cover® and American Express®). tronically sent to the viewer's own television set. The viewer 

The department store, on the other hand, might only is then biUed at the end of the month as part of the cable bill, 
accept a few of these forms of payment, such as cash, local „ For another example, a computer user might wish to pur- 
checks, its own charge card, and American Express®, while chase a «™<* from an on-line service provider whereby the 
not accepting other forms of payment. The department store user sim P l y orders ™ d receives the s*™ 0 * elec ' 
often posts these accepted forms of payment at the point- tronically over a network communication system, such as 
of purchase counter Internet. Common on-line service providers include 

Durmg the purchased 40 CompuServe^, Dialog®, and America On-line®, 

purchaser mentally takes note of the forms of payment la addition to purchasing items using electronic devices, 

accepted by the department store. The purchaser then ten- peopk are beginning to automate their payment of such 

ders payment using a suitable payment method. If the items - After a good or service is received and a bill is 

purchaser chooses to pay with a personal check, the sales presented, many purchasers are starting to pay their bills 

clerk performs an authentication process. The clerk only 45 electronically, or through a check writing system such as the 

accepts the check if it is local, if the clerk recognizes the Checkfree® system. In these computerized payment 

person writing the check, or if the person presents another systems, the consumer instructs the service provider by 

piece of identification (e.g., a credit card or driver's license) telephone, computer terminal, or other telecommunications 

to verify the authenticity of that person who is offering the to pay various bills (especially recurring, monthly bills) 

check 50 without the consumer having to write a check for each bill. 

In the event the purchaser tenders a credit card to pay for u * s - Pat - , No - 5383,113 describes an example computerized 

the clothing article, the sales clerk performs a check to verify check wnung system. 

that the purchaser has sufficient funds in the credit card With the increasing demand to electronically purchase 

account and has not exceeded the spending limit imposed by and pay for goods and/or services, there are a number of 

the issuing institution. This is typically done by passing the 55 issues that arise. For instance, the purchaser must choose a 

purchaser's credit card through a magnetic-stripe card method of paying for the goods and/or services that is 

reader, such as a Verifone® system, that is located at the acceptable to the merchant. But this task is not so simple, 

point-of-purchase counter to electronically read the purchas- because the purchaser most likely will not have access to 

er*s account information contained in the magnetic stripe on payment methods that are accepted by the merchant. Unlike 

the credit card. The purchaser's account information is 60 a point-of-purchase transaction where the accepted payment 

validated on-line with the card issuer with respect to the methods are often posted, the purchaser in the electronic 

purchaser's account balance and spending limit. Assuming transaction is often blind to the requirements of the mer- 

that the verification process returns a normal status, the sales chant. 

clerk accepts the tendered credit card and consummates the Another issues concerns how to protect the purchaser's 

purchase. 65 wallet from the merchant. Given a choice, the merchant 

The complexity of a purchase transaction increases when would most likely choose one particular payment method 

moved from the point-of-purchase context, where the pur- (such as using the merchant's own charge card) that the 
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purchaser might not wish to use. Moreover, for obvious accepted payment methods that the merchant would accept 

reasons, it is in the purchaser's interest not to reveal his/her for sale of the goods and/or services. The purchase system 

bank account or credit card information to the merchant. An also includes a processor coupled to the purchaser and 

electronic purchasing system should block the merchant merchant databases. 

from access to the purchaser's payment options and to this 5 jo make a purchase, the purchaser submits a purchase 

confidential account information. request that identifies, among other things, a merchant, a 

Another concern is protection from fraudulent purchaser, the goods and/or services to be purchased, and a 

transactions, both on the part of the merchant and the purchase amount. The processor receives the purchase 

purchaser. For instance, how can the purchaser be sure that request and mediates the purchase transaction. The proces- 

the merchant is authentic and truly has the represented goods 10 sor and its software components are assumed to be inde- 

or services to sell? How can the purchaser know that he/she pendent of, and trusted by, both the purchaser and the 

will not be billed for more than the amount that was agreed merchant. 

upon? From the merchant side, how can the merchant be The processor accesses the merchant database according 
assured that the purchaser really exists and that payment will to the merchant identified in the purchase request to retrieve 
be forthcoming? These issues are less troublesome in a 15 the set of accepted payment methods which corresponds to 
point-of-purchase context because the purchaser and mer- ma t merchant. The processor also accesses the purchaser 
chant can see one another, the goods are often readily database according to the purchaser identified in the pur- 
apparent, and payment is typically tendered on the spot. cna se request to retrieve the set of personal payment meth- 
However, in an electronic purchasing system where the 0 ds wn i c h corresponds to that purchaser. The processor then 
purchaser might live in one state or country and the seller 20 computes an intersection of these two sets to derive a 
might live in another, these issues become rather important. common set of any available payment method that is both 
A suitable purchasing system should address these issues to accepted by the merchant and can be used by the purchaser 
reduce or prevent the occurrence of fraudulent transactions. f or purchase of the goods and/or services. The purchaser is 

Another issue that arises in the electronic environment is presented with the purchase amount and the common set of 

whether the purchaser has sufficient funds to pay for the 25 available payment methods to choose a most preferred form 

goods or services. Still another issue concerns how to of payment. Upon selection, the processor consummates the 

authenticate the purchaser and merchant, as there is no sale and signs with the purchaser's digital signature via a 

opportunity for either of them to visually authenticate one password or other verification to ensure for the merchant 

another like in the point-of-purchase context. that a completed transaction has occurred. 

Many of the issues raised above are born out of the According to another aspect of this invention, the proces- 

difBculty and complexity of converting from a "paper-trail" sor can evaluate whether there is sufficient funds in the 

purchase transaction system — where these concerns are preferred payment method selected by the purchaser. If there 

addressed in large part through the use of paper checks, is, the processor permits the transaction to continue; 

receipts, physical credit cards, debit cards, and penned 35 otherwise, if the account does not have sufficient funds, the 

signature verification — to a "paperless" computerized pur- processor will deny the transaction and ask the purchaser to 

chase transaction system. It is an object of this invention to select another payment method, if any, from the common 

provide a "paperless" electronic purchasing system which set. 

solves these above noted problems. According to another aspect of this invention, the pur- 

aq chaser is permitted to provide self-imposed purchase allow- 

SUMMARY OF THE INA/ENTION ances that are stored io me p Urchase r database. Different 

This invention provides an electronic computerized pur- purchase allowances can be imposed on different payment 
chasing system that is particularly well suited for an inter- methods. The purchase allowances are useful for parents 
active networked environment. The purchasing system per- who wish to prevent their children from making an exces- 
mits the purchaser to choose a desired product from a 45 sive expenditure. Upon receipt of the purchase request, the 
particular merchant, arrange a suitable payment method, and processor compares the purchase amount to the purchase 
confirm a purchase transaction all electronically and without allowance and denies the transaction if the allowance is 
any human interaction between the purchaser and merchant. exceeded, independent of the payment methods available. 
The purchasing system of this invention mediates the pur- According to yet another aspect of this invention, the 
chase by providing a choice of suitable payment methods 50 purchasing system examines a purchaser's spending limits 
from which a purchaser can select a desired method, while for some of the payment methods before consummating a 
preventing the merchant from gaining access to the pur- transaction. Such spending limits are imposed and main- 
chaser personal payment options or account information. tained by the institutions that administer the payment 
Additionally, the purchasing system ensures for the mer- method, such as a bank or credit card company. After the 
chant that the purchaser has sufficient funds in the selected 55 purchaser selects a preferred payment method, the processor 
account, and that a fully enforceable transaction has inquires to the issuing institution as to the purchaser's 
occurred. The purchasing system of this invention also spending limit for that payment method. The processor then 
authenticates the communicating terminals and software compares the purchase amount to the associated spending 
applications to reduce or prevent fraudulent transactions. limit and denies the transaction if the limit is exceeded. 

According to one aspect of this invention, an electronic 60 In one preferred implementation, an interactive television 

purchase mediating system includes a purchaser database system is equipped with the purchasing system to facilitate 

having a list of purchasers and a merchant database having electronic purchases. The interactive television system 

a list of merchants. The purchaser database stores informa- includes a head end server, plural set-top boxes, and a 

tion about each purchaser including a set of personal pay- distribution network interconnecting the headend server and 

ment methods that the purchaser could use to purchase 65 set-top boxes. The set-top boxes are configured to operate in 

goods and/or services. Similarly, the merchant database a program mode where the corresponding television displays 

stores information about each merchant including a set of selected television programs and in a sales mode where the 
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corresponding television displays a user interface which ment methods in his/her corresponding set to purchase the 

facilitates the purchases of goods and/or services. Each goods and/or services from a merchant. 

set-top box has an input mechanism (such as a keypad or a As part of this registration, the purchaser is permitted to 

remote control device) that permits a requesting subscriber self-impose personal purchase allowances to prevent exces- 

to enter a purchase request to buy goods and/or services 5 sive expenditure. These purchase allowances can be asso- 

from a designated merchant. The purchase request is sent to ciated with different personal payment methods to selec- 

the head end server where the purchaser and merchant lively control expenditures for specific payment methods. 

databases are located. As above, a common set of available F ™ example, the purchaser may wish to restrict purchases 

payment methods are derived and provided to the subscriber usin S the CTedit card below one allowance level, while 

on his/her television for selection. The subscriber uses the to P laclD S a different allowance level on purchases using the 

input mechanism for the set-top box to choose the desired debit card Alternatively, the purchase allowances might be 

payment method imposed on a purchaser basis, whereby each purchaser is 

, t . . . ,.- , , given an allowance regardless of the chosen form of pay- 

Id add.taon to an mteractive tckram system, the dec- ^ ^ ^ ^ ^ ^ ^ be 

borne purchase mediating system of this invention can be ame ^ hl ^ , vli ^^ m ^ tmlstMlkbyait 

used with other interactive networks, mcluding wide area 15 . m . . , 4 ' 

, , - , , same purchase allowance. Jnis enables the parents to pre- 

networks, telephone networks, satellite networks, on-line , . , . f . r 

t j i t , vent excessive expenditures that a child might accidentally 

networks, and internet. attempt to make. To extend this concept farther, the system 

According to other aspects of this invention, a method for can ^ bc configured to support a different purchase 

facilitating an electronic purchase transaction of goods and/ ^ allowance for each family member, where the parents have 

or services is also described. higher allowances than the children. Individualized purchase 

allowances requires registration of each family member (or 
purchaser) so that the system can uniquely identify each 

FIG._1 is .a diagrammatic illustration of a computerized person, 

purchasing system according to this invention that canbe 25 Purchaser database 16 also stores account balances for 

used in conjunction with various types of interactive net- each of the personal payment methods of each purchaser, 

works and remote terminals. These account balances are used by the transaction process- 

FIG. 2 conceptually illustrates the computational task of ing urn* 12 to verify that the purchaser has sufficient funds 

deriving an intersection between two sets that is performed to purchase a desired product. Similarly, transaction pro- 

by the purchase mediating system of this invention. 30 cessing unit 12 examines an associated spending limit for 

FIG. 3 is a diagrammatic illustration of an interactive ««* P*? 0 *? 1 P**™"! L mc f hod ' Spending limits are imposed 

television system for facilitating electronic purchases of and mamtamed by the institutions that administers the 

goods and/or services according to one preferred implemen- P a y ment method ' ^ ch as an m™* j> ank °I CTedlt card 

tation of this invention. company, to prevent excessive expenditure. For example, 

, . 35 most credit cards are issued by the sponsoring bank or 

FIG. 4 B a block chagram of a purchase ^ting system associatio „ ^ m & ^ 

used in the interactive television system of FIG. 3. _ . . 4 " . r , l4 . , . . 

J Purchasing system 10 also has multiple purchasing ter- 

FIG. 5 is a user interface that is displayed on a television minals lg _ 23 bcated remotely from transaction processing 

of the interactive television system during a purchase trans- unit u Purchasing terminals 18-23 are illustrated as many 

actl0n * 40 different types of electronic devices, including a point-of- 

FIGS. 6 and 7 are a flow diagram of a method for purchase register 18, a personal computer 19, a telephone 

facilitating an electronic purchase transaction of goods and/ 20, a stand-alone machine 21 (e.g., an ATM), a television 

or services using the interactive television system. and set-top box unit 22, and a magnetic-stripe credit card 

reader 23 (e.g., a Verifone® reader). Each purchasing ter- 
45 minal has an input device which can receive a purchase 
request from a purchaser to buy goods and/or services from 

FIG. 1 shows a computerized purchasing system 10 for a merchant. The input device can be in the form of a keypad 

facilitating electronic purchase transactions over an interac- (as in the case of the register 18, telephone 20, stand-alone 

live network. Purchasing system 10 includes a centrally machine 21, and card reader 23) or a keyboard or mouse (as 

located transaction processing unit 12, a merchant database 50 in the case of computer 19), or a remote control device (as 

14 and a purchaser database 16, which are both provided at in the case of a remote for the TV and set-top box unit 22). 

the transaction processing unit. The merchant database 14 These illustrated purchase terminals are only a representa- 

ma in tains a list of merchants and financial information tive sample, as many other electronic devices can be used to 

concerning them. The financial information includes a set of make purchases in the computerized purchasing system of 

the merchant's accepted payment methods, whereby the 55 this invention. 

merchant is willing to accept any one of its accepted An interactive communication network 24 provides the 

payment methods for the sale of its goods and/or services. interfacing between the remotely located purchasing termi- 

For each of the accepted payment methods, the merchant nals 18-23 and the centrally located transaction processing 

database further contains the merchant's identification num- unit 12. The interactive communication network can be in 

ber and account information. 60 many different forms which are suitable to couple the 

The purchaser database 16 maintains a list of purchasers various types of purchasing terminals to the transaction 

and their associated personal financial information. The processing unit. For example, the interactive communication 

purchaser database stores a set of personal payment methods network can be configured as a wide area network, a 

(such as checking, credit cards, debit cards, Automated telephone network, a satellite network, an on-line network, 

Clearing House (ACH) Transfer, etc.) which are registered 65 or the Internet network. Another example is an interactive 

by the purchaser with the transaction processing unit. A television network, which is described below in more detail 

purchaser can use any one of the registered personal pay- as one preferred implementation. 



DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 
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To make a purchase using the computerized purchasing 
system 10, a purchaser initiates a purchase request at one of 
the purchasing terminals 18-23. In its simplest form, the 
purchase request includes the identity of the merchant, the 
identity of the purchaser, and a purchase amount. The 5 
purchase request is sent from a purchasing terminal, over the 
communication network 24, to transaction processing unit 
12. Upon receipt, transaction processing unit 12 does a 
preliminary evaluation to determine whether the purchase 
amount exceeds the personal purchase allowance associated 10 
with the identified purchaser. If it does, the purchase trans- 
action is denied to prevent the excessive expenditure and the 
purchaser is informed that the purchase amount is more than 
the purchase allowance. On the other hand, if the purchase 
allowance is not exceeded, the transaction processing unit 15 
begins gathering information related to the purchaser and 
merchant involved in the transaction. 

The transaction processing unit 12 accesses the merchant 
database 14 according to the merchant identified in the 
purchase request to retrieve the set of accepted payment 20 
methods which corresponds to that merchant. The process- 
ing unit 12 also accesses the purchaser database 16 accord- 
ing to the purchaser identified in the purchase request to 
"retrieve the set of personal payment methods which corre- 
sponds to that purchaser. 25 

Apayment method filter 26, shown resident at transaction 
processing unit 12, is operable to receive the set of merchant 
accepted payment methods and the set of personal payment 
methods. The payment method filter computes an intersec- 
tion of these two sets to derive a common set containing any 
available payment methods that is both accepted by the 
merchant and can be used by the purchaser to purchase the 
goods and/or services. Preferably, the payment method filter 
is implemented as a software program running on the 
transaction processing unit 12, or as a software program 
running on certain ones of the purchasing terminals 18-23 
(e.g., the stand-alone machine, PC computer, or set-top box), 
or as complementary software running at both the transac- 
tion processing unit and one or more purchasing terminals. 

The software-controlled processor is a trusted third party 
which is trusted by, and independent of, both the merchant 
and purchaser. The payment method filter 26 therefore acts 
as a trusted electronic mediator between the merchant and 
purchaser to derive common forms of acceptable payments, 45 
without revealing confidential account information to either 
one. 

FIG. 2 illustrates the underlying intersection computation 
performed by payment method filter 26. FIG. 2 shows a first 
or merchant set 28 of payment methods that are accepted by 50 
the merchant. Included in set 28 are payment methods 1, 2, 
3, 5, and 7, with examples being a merchant-issued charge 
card, cash on account, Discover®, VISA®, and Master- 
Card®. A second or purchaser set 30 contains four personal 
payment methods that are registered by the purchaser with 55 
the purchasing system. Payment methods 2, 4, 5, and 6 are 
included in this set 30, with examples being cash, personal 
check, VISA®, and American Express®. The intersection of 
these two sets 28 and 30 is represented by the overlapping 
area of the Venn circles. This intersection defines a common 59 
set 32 having mutually agreeable payment methods 2 and 5 
(e.g., cash and VISA®). The payment methods within 
common set 32 are both accepted by the merchant and part 
of the purchaser's personal options for payment. 

In the event that common set 32 contains more than one 65 
available payment method, which is the case in FIG. 2, the 
various payment methods are presented to the purchaser at 



40 



the purchasing terminal for his/her selection. Preferably, the 
payment options are presented in a prearranged sequence 
according to the purchaser's preferred order of use, such as 
cash first, followed by VISA®. Alternatively, if the pur- 
chaser has not noted a preferential order, the payment 
options can be presented according to the merchant's pre- 
ferred order of use or the network operator's preference. The 
purchaser selects a preferred option using the input device of 
the purchasing terminal. In those situations where the pay- 
ment method filter 26 returns a null or empty common set, 
the transaction processing unit 12 denies the transaction for 
failure to find a mutually agreeable payment form. 

The trusted processing unit and payment method filter 
derive a common set 32 of available payment methods 
without revealing the purchaser's "wallet" to the merchant. 
The different forms of payment that a purchaser can use, and 
their associated account numbers, are not released to the 
merchant. The merchant simply knows that an acceptable 
payment method has been agreed to by the purchaser. 

Once a common set of available purchase methods has 
been found and the purchaser has selected a preferred 
option, the transaction processing unit 12 evaluates whether 
the purchase amount contained in the purchase request 
exceeds an account balance of the selected payment method. 
For instance, if the purchaser selects payment method 2 
(e.g., cash) from common set 32, the transaction processing 
unit examines whether the purchaser's cash reserves will 
cover the purchase amount of the product. If the purchase 
amount exceeds the cash account balance, the purchasing 
terminal presents another available payment method, if any, 
for a new selection. If it turns out that the purchaser does not 
have sufficient funds in any acceptable payment method 
from common set 32, the transaction is terminated for lack 
of sufficient funds. This procedure assures the merchant that 
the purchaser can pay for the goods and/or services. 

Additionally, the transaction processing unit 12 deter- 
mines whether the purchase amount exceeds a spending 
limit of the selected payment method. For example, if the 
purchaser selects payment method 5 (e.g., VISA®), the 
processing unit checks whether the spending cap imposed by 
the issuing bank for the VISA® account is exceeded as a 
result of the purchase. If either the account balance or 
spending limit is exceeded, the transaction processing unit 
denies the request and informs the purchaser via the pur- 
chasing terminal. 

If the purchase request satisfies the tests of the transaction 
processing unit, the purchaser is given one last opportunity 
to confirm or cancel the purchase transaction. If the pur- 
chaser confirms the purchase transaction, the processing unit 
attaches an unforgeable digital signature on behalf of the 
purchaser to authorize the purchase and to validate for the 
merchant that a sale has been consummated. The digital 
signatures are produced using signing tools, such as cryp- 
tographic signing keys, which are unique to corresponding 
purchasers and are stored in the purchaser database. A 
password entered by the purchaser authorizes the processing 
unit to use his/her associated signing tool kept in the 
purchaser database. This digital signature assures the mer- 
chant that a legally enforceable purchase transaction has 
occurred. 

In some cases, the purchasing system might require an 
initial procedure to authenticate the purchaser (or merchant). 
For instance, the purchasing system might ask the user to 
input a personal identification number (PIN) before com- 
mencing the purchase transaction to verify the purchaser's 
authenticity. Another technique is to employ secure access 
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hardware, such as smart card and reader, at the purchasing same or staggered times. For example, one household might 

terminal. The smart card can be programmed with informa- request a video data stream at 8:00 pm, and a second 

tion about the user that is used to gain access to the household might request the same video data stream at 8:02 

purchasing system, such as the user's PIN or signature tools pm. This situation is easily accommodated by slightly stag- 

(e.g., a signing pair of encryption keys). Once the smart card 5 gered pointers to the same video data stream beginning at the 

is inserted into the terminal, the purchasing system performs same memory location. 

the cardholder authentication automatically. Database server 62 stores program descriptive informa- 

FIG. 3 shows an interactive television system 40 for tion used by the electronic programming guide (EPG) or 

facilitating electronic purchases of goods and/or services other menus, such as a movie -on-demand menu. The data- 

according to one preferred implementation of this invention. 10 base server stores such data as the program tide, actor 

Interactive television system 40 includes a centralized head information, whether the program has closed caption or 

end server 42 which is configured to provide both television stereo, the scheduled viewing time, the network name, the 

programming services and financial transaction services to program category, and a description text. The program 

multiple homes, of which representative homes 44(l)-44(/n) information is used to update the EPG or other menu as the 

are shown. A single head end server 42 might be designed, 15 user scrolls through them. 

for example, to service 250,000 homes. Each home 44(1) Database server 62 also holds pointers to memory loca- 
-44(m) is depicted for explanation purposes as having at tions within the continuous media server 60. The pointers 
least one set-top box (STB) 46(l>-4^) coupled to at least identify the storage locations of the video data streams of the 
one television 48(l)-48(m), and a remote control handset movies. According to this interactive television system 40, 
50(l)-50(/w). The set-top boxes are connected to receive 20 me viewer smi piy selects the movie of his/her choice from 
signals from head end server 42. As is customary, the set-top a menu on the screen and the head end server retrieves the 
boxes control which programs are displayed on their asso- digital video data stream from the continuous media server 
ciated televisions, 60 using the pointers from database server 62 and transmits 
Head end'server 42 is interconnected to the end viewers' the digital video data stream to the requesting set-top box for 
homes 44(l)-44(m) via a multi-tier distribution structure 52. 25 display on the associated television. 
Distribution structure 52 includes a high speed, high band- Interactive television system 40 also includes a financial 
width fiber optic cable network 54 coupled to many regional transaction system 64 which facilitates the purchase of 
distribution nodes (represented by distribution node 56). The goods and/or services between an ITV subscriber and a 
speed and bandwidth of fiber optic cable affords the desired merchant. The financial transaction system 64 resides pri- 
performance for supporting a fully interactive television marily at headend server 42, although portions of the system 
system. Each distribution node 56 is connected to multiple are provided at the STBs 46(1)-46(/m). 
STBs 46(1;M6(/h) via conventional home entry lines 58, mG 4 & ows a more det ailed block diagram of the 
such as twisted-pair lines, coaxial cable, or fiber. As an financial transaction system 64. It has a pricing system 70, 
example, each distribution node 56 supports approximately a taxing system 72> a purchasing system 74, and a transac- 
500-1200 homes. As technology continues to improve, it is non routmg system 76. Pricing system 70 is configured to 
believed that parts of the distribution structure can be rece ive an unpriced purchase transaction from a transaction 
replaced with wireless forms of communication, such as RF application 78 at set-top box 46(1) and establish pricing and 
communication or satellite communication. discounting information. From the perspective of the trans- 
Head end server 42 transmits traditional broadcast and ^ action application 78, pricing system 70 operates like a 
cable programming over multiple channels to each home, lookup table whereby for a given product, a price and 
much like the familiar conventional cable television sys- discount information are returned. However, the pricing 
lems. The programs are embodied as digital video data system is rather complex in that it provides pricing and 
streams that are transmitted from head end server 42 over discounting information in a quick time frame, because the 
distribution structure 52 to homes 44(l)-44(m). The head 4S subscriber is given an opportunity to confirm or deny the 
end server receives the video signals from another source, purchase in real-time and needs to review the applicable and 
such as a broadcast signal, a satellite feed, or other cable exact pricing information. The pricing system might also use 
system. information in the subscriber database for features such as 

Head end server 42 also provides additional services, such coupons or frequent buyer programs, 

as movie -on-demand and an electronic programming guide. 50 The taxing system 72 determines an appropriate tax for 

In FIG. 3, head end server 42 is shown as having a the sales transaction. Because different subscribers to the 

continuous media server 60 and a program database server interactive televisions system live in different regions of the 

62. Continuous media server 60 stores the digital video data country, the taxing system first determines the tax areas 

streams for selected movies that are to be provided on which have jurisdiction over the subscriber. Such tax areas 

demand to an individual household. The continuous media 55 include city, county, state, national, and special governments 

server is preferably implemented as a disk array data storage like a regional transit authority. Oftentimes, multiple taxes 

system consisting of many large capacity storage disks, each apply to a single product. The taxing system also determines 

on the order of one to several Gigabytes. The video data the product category because goods and services are treated 

streams of the movies are stored digitally on the storage differently in different jurisdictions, 

disks in predetermined or mapped locations. The locations 60 Qnce a particular transaction has an appropriate price and 

of the video data streams are kept in a memory map and each tax, control is transferred to the purchasing system 74 which 

video data stream can be accessed through pointers to the js implemented in software running on processors located at 

particular memory location. both the head end server 42 and set-top box 46(1). Purchas- 

The continuous media server can service simultaneous ing system 74 is coupled to a subscriber subsystem 80 and 

requests to view a movie on demand (even the same movie) 65 a merchant subsystem 82. The subscriber subsystem 80 

from thousands of homes. The digitally stored video data includes a database 81 containing a list of subscribers 

streams can be accessed by any number of viewers at the correlated with their personal account information, and 
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namely, their associated sets of personal payment methods. product (step 208 in FIG. 6). At step 210, the pricing system 
Hie merchant subsystem 82 includes a database 83 which 70 and taxing system 72 are invoked to assign the appro- 
stores a list of merchants correlated with their associated sets priate price and tax to the product, thereby yielding an 
of accepted payment methods, and account information for overall purchase amount. The price, tax, and total purchase 
each method. These databases store similar content to those 5 amount are displayed in alphanumeric box 106 of UI 100. It 
described above with reference to FIG. 1. is noted that in an alternative implementation, the purchase 

Purchasing system 74 has a purchase mediator 84 which mediator might provide the price and tax on its own without 

mediates the purchase transaction between the merchant and reference to the pricing system 70 and taxing system 72. A 

subscriber. The purchase mediator consists primarily of a resultant purchase request therefore contains at least an 

user interface (UI) code running on the set-top box in the 10 identity of the requesting subscriber and designated 

subscriber's home. More particularly, the set-top box can be merchant, and the purchase amount, 

operated in a sales mode where the corresponding television At step 212 in FIG. 6, purchasing system 74 transfers the 

displays the purchase mediator UI to facilitate purchases of purchase request over the distribution network from set-top 

goods and/or services from various merchants. The sub- box 46(1) to head end server 42 (FIG. 4). The head end 

scriber employs the UI and an input mechanism, such as the 1S server portion of purchasing system 74 indexes the list of 

remote control handset, to enter a purchase request for a merchants kept in merchant database 83 to retrieve the set of 

particular good and/or service from a designated merchant. accepted payment methods and account information that 

The purchase mediator helps determine a mutually agreeable corresponds to the merchant identified in the purchase 

payment method that is both accepted by the designated request (step 214). The list of subscribers in subscriber 

merchant and one of the requesting subscriber's personal 20 database 81 is also indexed to retrieve the set of personal 

payment methods, and then presents these options to the payment methods, spending limits, self-imposed purchase 

subscriber. allowances, account balances, and any other financial infor- 

FIG. 5 shows one example user interface 100 that the mation that corresponds to the subscriber identified in the 
purchase mediator can have displayed on the television. UI purchase request (step 216). It is noted that the ability to 
100 includes a text box 102 for the merchant's name, a text 2S index these databases and pull up real registered parties 
box 104 for a short description of the product, an alphanu- hel PS ensure that the transaction involves registered, 
meric box 106 for showing the price, tax, and purchase legitimate, identifiable parties, and is not a fraudulent trans- 
amount of the product, and a space 108 for a sponsoring action. 

logo. It is noted that the text boxes 102 and 104 can also be At this point, the purchasing system 74 examines whether 

used to display logos in bit map form or other custom 30 me purchase amount exceeds a purchase allowance that has 

display, such as animation. UI 100 further includes a spin been imposed by the subscriber (step 218 in FIG. 7). If it 

dial 110 which presents the available payment methods in a does (i.e., the "yes" branch from step 218), the purchasing 

sequential order, and if desired, in a prearranged order system denies the request and informs the subscriber that the 

according to the subscriber's preferences. Spin dial 110 purchase amount exceeds the purchase allowance (step 220). 

might also include logos of the sponsoring institution, such 35 Conversely, if the purchase allowance is not exceeded (i.e., 

as a logo for a bank or affinity organization (e.g., SeaFirst the "no" branch from step 218), the purchasing system 

Bank® or United Mileage Plus First Card®) or a card derives an intersection of the set of personal payment 

association logo (e.g., Discover®). A cancel button 112 and methods and the set of accepted payment methods to yield 

a buy button 114 enable the subscriber to accept or deny the a common set that comprises any available payment meth- 

transaction before any money exchanges hands. A focus 40 mat are acce P te d by the merchant and can be used 

frame, or the like, can be manipulated in the UI to highlight by the purchaser for purchase of the goods and/or services 

the active box. FIG. 5 is but one example arrangement of (step 222). 

information that can be presented to the subscriber, and The intersection derivation can be computed at one of two 

many other arrangements with more or less information can locations: at the head end server or at the set-top box. If the 

be used. 45 intersection computation is performed at the head end server 

With reference to FIGS. 4 and 5, and the flow diagram of 42, the common set is transferred back to set-top box 46(1) 

FIGS. 6 and 7, a method for electronically transacting a (step 224 in FIG. 7). Otherwise, if performed at set-top box 

purchase over an interactive television system wilt now be 46(1), the full two sets of information are sent to set-top box 

described. At step 200 (FIG. 6), a list of purchasers (i.e., the where the purchasing system then performs the intersection, 

subscribers) who have registered with the head end server 50 I* is more preferred to have the computation performed at 

are stored in the subscriber database 81. At step 202, a set of head end server 42 because less data is transferred between 

personal payment methods for each purchaser is stored in the head end server and set -top box. 

the subscriber database in a correlated manner for easy At step 226, the available payment methods contained in 

indexing. Similarly, a list of merchants and their correspond- the common set are presented to the subscriber using UI 100. 

ing sets of accepted payment methods are stored in the 55 More particularly, the available payment methods are 

merchant database 83 (steps 204 and 206 in FIG. 6). The arranged in sequential order, according to the subscriber's 

initial steps 200 to 206 of establishing subscriber and preference, and presented as a spin dial 110 in UI 100. The 

merchant databases need not be sequentially performed (as subscriber selects the default payment method, or cycles 

shown for purposes of illustration), but are more likely to through any alternative choices, to inform the purchasing 

occur concurrently. The subscriber database and merchant 60 system of a desired payment method. In this manner, the 

database are formed over time as new viewers subscribe to subscriber has control of his/her own wallet, and the system 

the system and more merchants participate. is not biased toward any particular option. It is noted that if 

The subscriber manipulates a focus frame in UI 100 using there are no available payment method, the purchasing 

an input device, such as the remote control handset, to select system denies the transaction and informs the user via UI 

a certain product for purchase from a designated merchant. 65 100 that no mutually agreeable payment method exists. 

Upon the subscriber's instructions, the purchase mediator 84 The subscriber selects a desired payment method using 

on set-top box 46(1) generates a purchase request to buy the the remote control handset for the set-top box (step 228). 
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The purchasing system evaluates the purchase request in from the subscriber account, and authorizes a corresponding 
view of the selected payment method. An initial test deter- deposit in the merchant account. Appropriate credit and 
mines whether the purchase amount exceeds an account debit entries are made in the general ledger, 
balance of the selected payment method (step 230). For The transaction routing system is coupled to a billing 
instance, suppose the selected payment method is cash, and 5 system 86, an acquisition system 88, and an accounting 
the subscriber has $1,200 in this account. Further, suppose system 90. These are example systems that handle the 
the purchase amount is $2,100. In this case, the purchase mechanics of submitting a bill to the subscriber and posting 
amount exceeds the subscriber's account balance (i.e., the the appropriate transaction in the acquiring account (such as 
"yes" branch from step 230) and the purchasing system a credit card account) and/or subscriber account, 
denies the transaction as to that payment method. The 10 Durin g the purchase transaction, the purchasing system of 
system then quickly checks to see if there are any other ^ iovention that a secure communication path 
mutually agreeable payment methods (step 232). If another ^ s{& btt9nm its software components on the centrally 
available payment method exists (i.e., the "no" branch from ]ocaled head end ^ itg ^ft^e components on the 
step 232), the subscriber is asked to pick a new payment remotely i ocated sm To ensure that a secure communica- 
option. On the other hand, if no more options exist (i.e., the 15 tion path ejdstSj tfae purchasing system employs cryptogra- 
«yes" branch from step 232), the purchase request is denied phy techniques to authenticate the communicating software 
(step 220). This procedure verifies for the merchant that the components . Digi tal certificates are assigned to each STB in 
subscriber chooses a payment method that contains suffi- ±c systcm and {o ^ head cnd Adigital ccrt ificate is 
cient funds or credit to pay for the goods, and thereby a packct of uniquc ^formation in digital data form that is 
protects the merchant from selling a product to a subscriber 20 used for identification 0 f a party in the encryption arena. The 
who might not be able to afford the product. certificate is issued by an independent and trusted third 
At step 234, the purchasing system further evaluates party, known as the "certifying authority". Every participant 
whether the purchase amount exceeds any spending limit trusts the certifying authority. An example certifying author- 
associated with the selected payment method by checking ity in this situation is the cable network operator of the. 
with the appropriate sponsoring institution. For this 25 interactive television system. 

example, suppose the selected payment method is a credit Each certificate contains an expiration date, the 

card having a credit limit of $5,000, and the purchase ho i der > s serial number, a public data exchange encryption 

amount is $8,000. Here, the purchasing system will learo key unique t0 me holder> a pubHc signing key unique to the 

upon checking with the card's issuing bank that the purchase holder> and a signature from the certifying authority. Before 

amount exceeds the credit card spending limit imposed by continuing discussion on how to secure a communication 

the issuing bank, and thus the transaction should be denied path ^tween the head end server and an STB, it would be 

for that payment method. As above, the subscriber is given beneficial to briefly discuss encryption techniques, and how 

an opportunity to select another payment method, if any are digital certificates m use d. There are different encryption 

available, via steps 232 and 228. ^ techniques available and in use today. This invention can be 

If the purchase request survives these various tests, the used with any type of encryption technique. For the sake of 

subscriber is presented with one final opportunity to cancel explanation, the basics of one common encryption technique 

the purchase. With reference to UI 100 in FIG. 5, the known as "RSA" (an acronym based on the initials of the 

subscriber uses buttons 112 and 114 to respectively cancel or creators of the encryption algorithm) are described below, 

confirm the purchase transaction. If the subscriber confirms, 4Q R SA encryption makes use of special mathematical func- 

the purchasing system attaches a digital signature of the nons re f erre d t o as "one-way" functions. According to 

purchaser to authorize the purchase (step 236 in FIG. 7). one-way functions, one or more starting parameters can 

This assures the merchant that the purchaser is real, has un dergo a function to yield an intelligible result, but the 

sufficient money, will pay for the goods, and has legally mV erse function operating on this result will not produce the 

signed for the goods. 45 s t ar ting parameters. In mathematical terms, a one-way func- 

The above evaluation steps for a selected payment method tion F is represented as follows: 
can be made in alternative sequences. For instance, the 

purchasing system might attach the digital signature (step *"(«>^ but f-^fy^a. 

236) following selection of a payment method. The system „ , , , . , . . , , . t . 

, ' . & . v 1 c ii_ i_ r Such functions are used to produce private and pub he 

l ^z^zT^ a 2ltrtz2t 50 which ™r g ^° e r party 

„ . 4 , j r .t . . -j j - * j wishes to participate in encrypting and decrypting messages. 

Furthermore, the order of the tests provided in steps 230 and , \. \ , . ,u „ i * i 1 

, , . 4 .„ . .. 4l _ r . The key set is unique and has the property that if one knows 

234 can be reversed. As still another variation, the purchase . ' . J} « .u * 1 

allowance test of step 218 might be performed after the £ ' T'lbfctad for eve^one to 

payment method is selected in the event that the purchaser « ^v™*' P \ / r*" w £ P . . .... 

* J . , ,.~ „ , „ c . , 3 use, while the private key IC,^,, is kept secret by the 

has imposed different purchase allowances for individual DO i der r j 

payment methods. p or a messa g C that is encrypted via an encryption 
With reference again to FIG. 4, the consummated pur- function E and decrypted via a decryption function D using 
chase transaction is forwarded from purchase mediator 84 to one of the public or priva te keys or Kp„ v ^, the 
transaction routing system 76 which logs the transactions in 60 following holds: 
a general ledger and routes the transactions to the appropri- 
ate system for approval and posting to the subscriber's EKpuUic(M)-M e!tC w**-i 
account. More particularly, the transaction routing system 76 
journals each transaction for audit purposes and logs each 
transaction against an appropriate account in the general 65 ^ ut 
ledger. The transaction routing system selects a subscriber 

account, selects a merchant account, authorizes a withdrawal D^ Wic (NWy^— i)* M 
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Additionally, This encryption scheme therefore ensures for the receiv- 
ing party (i.e., the head end server in this example) that the 

E K Pr tvat e W-M merged— i communication is from the desired sending party (i.e., the 

. STB) and that only the receiving party can read the original 

d^^m^^m 5 message . 

but^ The encryption scheme only works, however, if the head 

end server and STB trust each other's identity. Accordingly, 

^Kprivate (M»kt>p.«#-2>*M the "certifying authority" is introduced as a trusted third 

e . . ... party to the communication. The head end server and STB 

Accordingly, m the context of our interactive television 1Q eacfa theif identity tQ me satisfaction of the certifying 

system, if the set-top box encrypts a message using the head authority and deposil meir pub]ic keys ^ this aut hority. In 

end server's public key, only the head end server can decrypt me • authority issues a digital certificate that 

it. Furthermore if the set-top be* encrypts a message using afl expiration datCj the holder > s xM number, a 

its pnvate key (which only the STB can do since no one else ^ encryption key to holder> a pri vate 

has access to this private key), any other party can decrypt 15 si ^ ^ and othef MotmiioD ap p ropr i a te to estab- 

the text using the STB s public key which is widely known. Hsh communication. The identification information is 

To establish communication for the purchase transaction, encTypt cd using the certifying authority's private key, as 

the requesting STB and head end server initially exchange follows* 
their respective digital certificates. The STB then sends a 

message to the head end server using the head end server's 2Q Certificate^E^^^^^^ (Expiration, Card Serial #, K. sr3 _ pubnc , 

public key of the data exchange key pair that it received in etc ^ 

the head end server's certificate. Only the head end server During the initial communication, the STB and head end 

can decrypt that message by using its own private key of the server exchange their certificates. Both the STB and head 

_data exchange key pair. In a similar fashion, the head end end server decipher the other's certificate using the certify- 

server can encrypt a reply message using the STB's public 25 m g authority's public key. Trie STB and head end server can 

data exchange key and only the requesting STB can decrypt eacn be assured that it is talking to the other legitimate party 

that message. if the certificate deciphers into intelligible information. It is 

This raises a new issue. When the STB or head end server practically impossible for either the head end server or STB 

receives an encrypted message that is supposedly from the to construct a fraudulent certificate because neither knows 

other, how does the receiving party really know if it came 3Q me private key of the certifying authority. In this manner, a 

from the other? Or in the context of a purchase transaction, secure path is established between the STB and head end 

how does the head end server really know that the purchase server to facilitate the purchase transaction described above, 

request came from a legitimate subscriber or legitimate The computerized purchasing system of this invention 

STB? provides many benefits. One benefit is that it automatically 

To solve this dilemma, encryption algorithms introduce 35 determines a set of mutually agreeable payment methods 

"digital signatures" which ensure that the appropriate parties without revealing any confidential account information to 

are communicating with each other. A digital signature is either the purchaser or merchant. Another benefit is that it 

computed by hashing the data contained in the message sent a {ds in preventing fraudulent transactions, both on the part 

between the STB and head end server. A hash function is a of the merchant and the purchaser, by automatically medi- 

mathematical function that converts an input data stream ^ a ting the purchase and ensuring that the subscriber and 

into a fixed-size, often smaller, output data stream that is merchant actually exist. Another benefit is that it provides 

representative of the input data stream. Suppose that the confidence to the merchant that the purchaser has sufficient 

STB wishes to encrypt and sign a message destined for the frnds to purchase the goods. Still another benefit is that it 

head end server. The STB computes a hash of the message prevents the purchaser from over spending beyond personal 

and then uses its private signing key to encrypt the resultant 45 purchase allowances and spending limits imposed on the 

digest, as follows: payment methods. 

In compliance with the statute, the invention has been 

tc-^t^^i^—isn k r described in language more or less specific as to structural 

where the "E" denotes an encryption function on the hash of and methodical features. It is to be understood, however, that 

the message "HM" and the subscript "K^^,^,^^" 50 me invention is not limited to the specific features described, 

means the STB's private key of the signing key pair was sincc thc means hcrcin disclosed comprise preferred forms 

employed to perform the encryption. The head end server of putting the invention into effect. The invention is, 

will be able to verify the STB's digital signature by decrypt- therefore, claimed in any of its forms or modifications within 

ing the hash using the STB's public signing key, indepen- toe proper scope of the appended claims appropriately 

dently computing the hash of the original message, and 55 interpreted in accordance with the doctrine of equivalents, 

comparing the locally computed hash with the decrypted We claim: 

hash. The comparison will succeed only if the STB's private 1- An electronic purchase mediating system comprising: 

signing key was used to encrypt the hash. Since only the a purchaser database having a list of purchasers, the 

STB knows the private signing key, the head end server can purchaser database also storing a set of many personal 

be assured that the STB actually created the encrypted hash, 60 payment methods for corresponding ones of the pur- 

essentially "signing" the message. chasers whereby an individual purchaser could use any 

Note that any party can intercept the communication one of the personal payment methods in that purchas- 

between the STB and head end server and use the STB's er's corresponding set to purchase goods and/or ser- 

public key to determine that the communication came from vices; 

the STB. However, that intercepting party cannot decipher 65 a merchant database with a list of merchants, the merchant 

the encrypted message because they do not know the head database also storing a set of many accepted payment 

end server's private key. methods for corresponding ones of the merchants 
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whereby an individual merchant is willing to accept 
any one of the accepted payment methods in that 
merchant's corresponding set for sale of the goods 
and/or services; 

a processor coupled to the purchaser and merchant 5 
databases, the processor also being coupled to receive 
a purchase request for goods and/or services, the pur- 
chase request identifying a merchant and a purchaser; 

the processor accessing the merchant database according 
to the merchant identified in the purchase request to 10 
retrieve the set of many accepted payment methods 
which corresponds to that merchant, the processor also 
accessing the purchaser database according to the pur- 
chaser identified in the purchase request to retrieve a set 
of many personal payment methods which corresponds 15 
to that purchaser; and 

the processor computing an intersection of these two sets 
to derive a common set of any available payment 
method that is both accepted by the merchant and can 
be used by the purchaser for purchase of the goods 20 
and/or services. 

2. An electronic purchase mediating system as recited in 
claim 1 wherein: 

the purchase request further includes a purchase amount; 25 
the purchaser database includes personal purchase allow- 
ances for associated purchasers, each personal purchase 
allowance being imposed by the purchaser to prevent 
an expenditure in excess of the personal purchase 
allowance; and 30 
the processor evaluates whether the purchase amount 
contained in the purchase request exceeds a personal 
purchase allowance associated with the identified pur- 
chaser. 

3. An electronic purchase mediating system as recited in 35 
claim 1 wherein: 

the purchase request further includes a purchase amount; 

the personal payment methods of the purchasers have 
associated spending limits, each spending limit being 
imposed and maintained by an institution that admin- 40 
isters the payment method to prevent an expenditure in 
excess of the spending limit; and 

the processor communicates with the institution to evalu- 
ate whether the purchase amount contained in the 
purchase request exceeds a spending limit of any 45 
available payment method in the common set. 

4. An electronic purchase mediating system as recited in 
claim 1 wherein: 

the purchase request further includes a purchase amount; sq 
the purchaser database includes account balances for 
corresponding ones of the personal payment methods 
for related purchasers; and 
the processor evaluates whether the purchase amount 
contained in the purchase request exceeds an account 55 
balance of any available payment method in the com- 
mon set. 

5. An electronic purchase mediating system as recited in 
claim 1 wherein: 

the purchaser database includes unique signing keys for 60 
creating digital signatures for corresponding ones of the 
purchasers; and 

the processor creates a digital signature on behalf of the 
identified purchaser to authorize the purchase of the 
goods and/or services. 65 

6. A purchasing system for use on an interactive network, 
the purchasing system comprising: 



a centrally located transaction processing unit; 

a merchant database provided at the transaction process- 
ing unit, the merchant database having a list of mer- 
chants and sets of accepted payment methods for 
corresponding ones of the merchants, whereby an indi- 
vidual merchant is willing to accept any one of the 
accepted payment methods in that merchant's corre- 
sponding set for sale of the goods and/or services; 

a purchaser database provided at the transaction process- 
ing unit, the purchaser database having a list of pur- 
chasers and sets of personal payment methods for 
corresponding ones of the purchasers, whereby an 
individual purchaser could use any one of the personal 
payment methods in that purchaser's corresponding set 
to purchase the goods and/or services; 

multiple purchasing terminals located remotely from the 
transaction processing unit, each purchasing terminal 
having an input device which can receive a purchase 
request from a purchaser to buy goods and/or services 
from a merchant, the purchase request identifying the 
merchant and the purchaser; 

an interactive communication network which interfaces 
the remotely located purchasing terminals with the 
centrally located transaction processing unit, the com- 
munication network transferring the purchase request 
from one of the purchasing terminals to the transaction 
processing unit; 

the transaction processing unit accessing the merchant 
database according to the merchant identified in the 
purchase request to retrieve the set of accepted payment 
methods which corresponds to that merchant, and fur- 
ther accessing the purchaser database according to the 
purchaser identified in the purchase request to retrieve 
the set of personal payment methods which corre- 
sponds to that purchaser; and 

a payment method filter operable to receive the set of 
merchant accepted payment methods and the set of 
personal payment methods and to compute an intersec- 
tion of these two sets to derive a common set containing 
any available payment methods that is both accepted by 
the merchant and can be used by the purchaser for 
purchase of the goods and/or services. 

7. A purchasing system as recited in claim 6 wherein: 
the payment method filter resides at the transaction pro- 
cessing unit; and 

the transaction processing unit transfers the common set 
back to the one purchasing terminal via the communi- 
cation network to inform the purchaser of any available 
payment methods. 

8. A purchasing system as recited in claim 6, further 
comprising: 

multiple payment method filters provided at correspond- 
ing ones of the purchasing terminals; and 

the transaction processing unit transfers the set of 
accepted payment methods retrieved from the merchant 
database and the set of personal payment methods 
retrieved from the purchaser database back to the one 
purchasing terminal via the communication network 
whereby a payment method filter resident at the one 
purchasing terminal computes the common set to 
inform the purchaser of any available payment meth- 
ods. 

9. A purchasing system as recited in claim 6 wherein: 
the transaction processing unit and payment method filter 

do not reveal to the merchant the set of personal 
payment methods of the purchaser. 
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10. A purchasing system as recited in claim 6 wherein: 

the purchase request further includes a purchase amount; 

the purchaser database includes account balances for 
corresponding ones of the personal payment methods 
for related purchasers; 5 

the one purchasing terminal presents the common set of 
available payment methods to the purchaser for selec- 
tion whereby the purchaser selects a desired payment 
method using the input device at the one purchasing 1(J 
terminal; and 

the transaction processing unit evaluates whether the 
purchase amount contained in the purchase request 
exceeds an account balance of the selected payment 
method. 15 
U. A purchasing system as recited in claim 10 wherein: 
in the event that the purchase amount exceeds the account 
balance of the selected method, the purchasing terminal 
presents to the purchaser another available payment 
method from the common set for selection. 20 

12. A purchasing system as recited in claim 6 wherein: 
the purchaser database includes unique signing keys for 

creating digital signatures of the purchasers; and 
the transaction processing unit creates a digital signature 
on behalf of the purchaser identified in the purchase 25 
request to authorize the purchase of the goods and/or 
services. 

13. A purchasing system as recited in claim 6 further 
comprising: 

smart cards assigned to corresponding purchasers; 30 
smart card readers located at ones of the purchase termi- 
nals; 

the smart cards storing unique signing keys for creating 
digital signatures for the corresponding purchasers; and 35 

the processor using a unique signing key to create a digital 
signature on behalf of the identified purchaser to autho- 
rize the purchase of the goods and/or services. 

14. A purchasing system as recited in claim 6 wherein: 

the purchase request further includes a purchase amount; 40 
the purchaser database includes personal purchase allow- 
ances for associated purchasers, each personal purchase 
allowance being imposed by the purchaser to prevent 
an expenditure in excess of the personal purchase 
allowance; and 45 
the transaction processing unit evaluates whether the 
purchase amount contained in the purchase request 
exceeds a personal purchase allowance associated with 
the purchaser identified in the purchase request. 

15. A purchasing system as recited in claim 6 wherein: 50 
the purchase request further includes a purchase amount; 
the purchaser database includes purchase allowances for 

corresponding ones of the personal payment methods 
of the purchasers, each personal purchase allowance ss 
being imposed by the purchaser to prevent an expen- 
diture in excess of the personal purchase allowance; 
and 

the transaction processing unit evaluates whether the 
purchase amount contained in the purchase request 60 
exceeds a personal purchase allowance associated with 
a particular payment method. 

16. A purchasing system as recited in claim 6 wherein: 
the purchase request further includes a purchase amount; 
the personal payment methods of the purchasers have 65 

corresponding spending limits, each spending limit 
being imposed and maintained by an institution that 
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administers the payment method to prevent an expen- 
diture in excess of the spending limit; and 
the transaction processing unit communicates with the 
institution to evaluate whether the purchase amount 
contained in the purchase request exceeds a spending 
limit of any available payment methods in the common 
set. 

17. A purchasing system as recited in claim 6 wherein: 
in the event that the common set derived by the payment 

method filter contains multiple available payment 
methods, the purchasing terminal presents the common 
set of available payment methods in a prearranged 
sequence according to the purchaser's preferred order 
of use for paying for the goods and /or services. 

18. A purchasing system as recited in claim 6 wherein: 
the communication network is selected from a group 

comprising wide area networks, interactive television 
networks, telephone networks, satellite networks, 
on-line networks, and the Internet network. 

19. A purchasing system as recited in claim 6 wherein: 
the purchasing terminal and the transaction processing 

unit have associated digital certificates, each digital 
certificate including a unique public key and a signature 
from a certifying authority; and 
a communication path within the communication network 
is secured by exchanging the digital certificates and 
encrypting communication using the public keys. 

20. An interactive television system for facilitating elec- 
tronic purchases of goods and/or services, the interactive 
television system comprising: 

a centrally located head end server; 

a plurality of set-top boxes located in subscribers homes 
for controlling content displayed on corresponding 
televisions and being operably connected to commu- 
nicate with the head end server, individual set-top 
boxes being configured to operate in a program mode 
where the corresponding television displays selected 
television programs and in a sales mode where the 
corresponding television displays a user interface 
which facilitates purchases of goods and/or services 
from merchants, the individual set-top boxes having an 
input mechanism that permits a requesting subscriber to 
enter a purchase request to buy goods and/or services 
from a designated merchant; 

a merchant subsystem provided at the head end server, the 
merchant subsystem including a database having a list 
of merchants correlated with associated sets of 
accepted payment methods, whereby an individual 
merchant is willing to accept any one of the accepted 
payment methods in that merchant's associated set for 
sale of the goods and/or services; 

a subscriber subsystem provided at the head end server, 
the subscriber subsystem including a database having a 
list of subscribers correlated with associated sets of 
personal payment methods, whereby an individual pur- 
chaser could use any one of the personal payment 
methods in that purchaser's associated set to purchase 
the goods and/or services; and 

a purchase mediator operable in response to the purchase 
request to determine an available payment method that 
is both accepted by the designated merchant and one of 
the requesting subscriber's personal payment methods, 
the purchase mediator deriving the available payment 
method from the set of accepted payment methods in 
the merchant subsystem that is associated with the 
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designated merchant and the set of personal payment 
methods in the subscriber subsystem that is associated 
with the requesting subscriber. 

21. An interactive television system as recited in claim 20 
wherein: 5 

the available payment method determined by the purchase 
mediator is displayed as part of the user interface on the 
television of the requesting subscriber. 

22. An interactive television system as recited in claim 20 
wherein: 10 

in the event that the purchase mediator derives multiple 
acceptable payment methods that are both accepted by 
the designated merchant and coincide with the request- 
ing subscriber's personal payment methods, the mul- 
tiple acceptable payment methods are displayed as part 15 
of the user interface on the television of the requesting 
subscriber in a prearranged sequence according to the 
requesting subscriber's preferred order of use for pay- 
ing for the goods and/or services. 

23. An interactive television system as recited in claim 20 20 
wherein: 

the purchase mediator resides at the head end server; and 
following determination of the available payment method 
-by the purchase mediator, the head end server transfers 
the available payment method back to the set-top box 25 
of the requesting subscriber for display as part of the 
user interface on the corresponding television. 

24. An interactive television system as recited in claim 20 
wherein: 

the purchase mediator resides at the set-top box of the 30 
requesting subscriber; and 

the head end server transfers the accepted payment meth- 
ods obtained from the merchant subsystem and the 
personal payment methods obtained from the sub- 
scriber subsystem back to the set-top box of the 35 
requesting subscriber where the purchase mediator 
locally derives any available payment method. 

25. An interactive television system as recited in claim 20 
wherein: 

the purchase request further includes a purchase amount; 40 
the subscriber subsystem database includes account bal- 
ances for corresponding personal payment methods for 
related subscribers; and 
the purchase mediator evaluates whether the purchase 45 
amount contained in the purchase request exceeds an 
account balance of the requesting subscriber with 
respect to any available payment method. 

26. An interactive television system as recited in claim 20 
wherein: 

the subscriber subsystem database includes signing keys 
for creating unique digital signatures of the subscribers; 

the available payment method determined by the purchase 
mediator is displayed as part of the user interface on the 
television of the requesting subscriber; 5S 

the displayed user interface further provides an option, 
responsive to selection by the input mechanism for the 
set-top box, which permits the subscriber to accept or 
reject transacting the purchase via the available pay- 
ment method; and 60 

whereupon acceptance of the purchase, the set-top box of 
the subscriber transmits an acceptance notice to the 
head end server which then digitally signs on behalf of 
the requesting subscriber to consummate the sale of the 
goods and/or services. 65 

27. An interactive television system as recited in claim 20 
wherein: 
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the purchase request further includes a purchase amount; 

the subscriber subsystem database includes personal pur- 
chase allowances for associated subscribers, each per- 
sonal purchase allowance being imposed by the sub- 
scriber to prevent an expenditure in excess of the 
personal purchase allowance; and 

the purchase mediator evaluates whether the purchase 
amount contained in the purchase request exceeds a 
personal purchase allowance associated with the 
requesting subscriber. 

28. An interactive television system as recited in claim 20 
wherein: 

the purchase request further includes a purchase amount; 

the subscriber subsystem database includes personal pur- 
chase allowances for associated personal payment 
methods, each personal purchase allowance being 
imposed by the subscriber to prevent an expenditure in 
excess of the personal purchase allowance; and 

the purchase mediator evaluates whether the purchase 
amount contained in the purchase request exceeds a 
personal purchase allowance associated with a payment 
method. 

29. An interactive television system as recited in claim 20 
wherein: 

the purchase request further includes a purchase amount; 

the personal payment methods of the subscribers have 
associated spending limits, each spending limit being 
imposed and maintained by an institution that admin- 
isters the payment method to prevent an expenditure in 
excess of the spending limit; and 

the purchase mediator communicates with the institution 
to evaluate whether the purchase amount contained in 
the purchase request exceeds a spending limit of any 
available payment method. 

30. An interactive television system as recited in claim 20 
wherein: 

each set-top box and the head end server have associated 
digital certificates, each digital certificate including a 
unique public key and a signature from a certifying 
authority; and 

the set-top box of the requesting subscriber and the head 
end server exchange their respective digital certificates 
to establish a secure communication path using encryp- 
tion techniques. 

31. A method for electronically transacting a purchase of 
goods anaVor services between a merchant and a purchaser, 
the purchaser having a set of multiple personal payment 
methods that can be used to purchase the goods and/or 
services and the merchant having a set of multiple accepted 
payment methods that are acceptable for the purchase of the 
goods and/or services, the method comprising the following 
steps: 

supplying the set of multiple personal payment methods 
and the set of multiple accepted payment methods to a 
trusted processor that is independent of, but trusted by, 
both the merchant and the purchaser; and 

deriving, at the trusted processor, an intersection of the 
sets to yield a common set that comprises any available 
payment methods that are both accepted by the mer- 
chant and can be used by the purchaser for purchase of 
the goods and/or services. 

32. A method as recited in claim 31 wherein: 

the deriving step yields a common set that is null of an 

available payment method; and 
the method further comprising denying the purchase of 

the goods and/or services. 
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33. A method as recited in claim 31 wherein: 

the deriving step yields a common set comprising mul- 
tiple available payment methods; and 

the method further comprising presenting the common set 
of available payment methods to the purchaser for 5 
selection of a preferred payment method. 

34. A method as recited in claim 33, further comprising 
the following additional step: 

successively presenting individual available payment 
methods from the common set in a prearranged 
sequence according to the purchaser's preferred order 
of use. 

35. A method as recited in claim 31, further comprising 
the following additional step: ^ 

preventing access of the merchant to the set of personal 
payment methods that can be used by the purchaser to 
purchase the goods and/or services. 

36. A method as recited in claim 31, further comprising 
the following additional step: 2Q 

verifying that the purchaser has sufficient funds in an 
account associated with any available payment method 
from the common set. 

37. -A method- as. recited in claim 31, further comprising _ 
the following additional step: 2 s 

attaching a digital signature on behalf of the purchaser to 
authorize purchase of the goods and/or services using 
the available payment method. 

38. A method as recited in claim 31, further comprising 
the following additional steps: 30 

permitting the purchaser to impose a purchasing limit to 
prevent excessive expenditure; 

comparing a payment amount for the purchase of the 
goods and/or services to the purchasing limit; and 

denying the purchase of the goods and/or services in the 35 
event the payment amount exceeds the purchase allow- 
ance. 

39. A method as recited in claim 31, further comprising 
the following additional steps: 

imposing spending limits in relation to respective ones of 40 
the personal payment methods of the purchaser, the 
spending limits being established by an institution that 
administers the respective ones of the personal payment 
methods; 

comparing a payment amount for the purchase of the 
goods and/or services to the spending limit related to 
the available payment method; and 

denying the purchase of the goods and/or services in the 
event the payment amount exceeds the spending limit. 5Q 

40. A method for facilitating an electronic purchase trans- 
action of goods and/or services between a merchant and a 
purchaser over an interactive network, the interactive net- 
work having distributed processing units, the method com- 
prising the following steps: 

storing a list of purchasers at a first processing unit; 

storing sets of personal payment methods for correspond- 
ing ones of the purchasers, whereby an individual 
purchaser could use any one of the personal payment 
methods in that purchaser's corresponding set to pur- 60 
chase the goods and/or services; 

storing a list of merchants at the first processing unit; 

storing sets of accepted payment methods for correspond- 
ing ones of the merchants, whereby an individual 
merchant is willing to accept any one of the accepted 65 
payment methods in that merchant's corresponding set 
for sale of the goods and/or services; 
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generating a purchase request for the goods and/or ser- 
vices at a second processing unit, the purchase request 
identifying a purchaser and a merchant; 

transferring the purchase request from the second pro- 
cessing unit to the first processing unit via the interac- 
tive network; 

indexing the list of purchasers to retrieve the set of 
personal payment methods that corresponds to the 
purchaser identified in the purchase request; 

indexing the list of merchants to retrieve the set of 
accepted payment methods that corresponds to the 
merchant identified in the purchase request; and 

deriving an intersection of the set of personal payment 
methods and the set of accepted payment methods to 
yield a common set that comprises any available pay- 
ment methods that are both accepted by the merchant 
and can be used by the purchaser for purchase of the 
goods and/or services. 

41. A method as recited in claim 40, further comprising 
the following step: 

after said deriving step, transferring the common set from 
the first processing unit back to the second processing 
unit via the interactive network. 

42. A method as recited in claim 40, further comprising 
the following steps: 

before said deriving step, transferring the set of personal 
payment methods and the set of accepted payment 
methods from the first processing unit back to the 
second processing unit; and 

deriving the intersection of the sets at the second process- 
ing unit. 

43. A method as recited in claim 40 wherein: 

the deriving step yields a common set that is null of an 

available payment method; and 
the method further comprising denying the purchase of 

the goods and/or services. 

44. A method as recited in claim 40 wherein: 

the deriving step yields a common set comprising mul- 
tiple available payment methods; and 

the method further presenting the common set of available 
payment methods to the purchaser at the second pro- 
cessing unit for selection of a preferred payment 
method. 

45. A method as recited in claim 44, further comprising 
the following additional step: 

successively presenting individual available payment 
methods from the common set in a prearranged 
sequence according to the purchaser's preferred order 
of use. 

46. A method as recited in claim 40, further comprising 
the following additional step: 

preventing access of the merchant to the set of personal 
payment methods that can be used by the purchaser to 
purchase the goods and/or services. 

47. A method as recited in claim 40, further comprising 
the following additional step: 

verifying that the purchaser has sufficient funds in an 
account associated with any available payment method 
from the common set. 

48. A method as recited in claim 40, further comprising 
the following additional step: 

attaching a digital signature on behalf of the purchaser to 
authorize purchase the goods and/or services using the 
available payment method. 
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49. A method as recited in claim 40, further comprising 
the following additional steps: 

providing purchasing limits in correlation to the purchas- 
ers stored at the first processing unit; 

comparing a payment amount for the purchase of the 5 
goods and/or services to a purchasing limit of the 
purchaser identified in the purchase request; and 

denying the purchase of the goods and/or services in the 
event the payment amount exceeds the purchasing Q 
limit. 

50. A method as recited in claim 40, further comprising 
the following additional steps: 

providing purchasing limits in correlation to the personal 

payment methods; 15 
comparing a payment amount for the purchase of the 

goods and/or services to a purchasing limit associated 

with a personal payment method; and 
denying the purchase of the goods and/or services in the 

event the payment amount exceeds the purchasing 20 

limit. 

51. A method as recited in claim 40, further comprising 
the following additional steps: 

providing spending limits in relation to respective ones of - 
the personal payment methods of the purchasers stored 25 
at the first processing unit, the spending limits being 
established by an institution that administers the 
respective ones of the personal payment methods; 

comparing a payment amount for the purchase of the 3() 
goods and/or services to the spending limit related to 
the available payment method; and 

denying the purchase of the goods and/or services in the 
event the payment amount exceeds the spending limit. 

52. A method as recited in claim 40, further comprising 35 
the following additional step: 

securing a communication path between the first and 
second processing units using encryption techniques. 

53. A computer readable medium having computer 
executable instructions for performing steps comprising: 
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receiving a set of multiple personal payment methods that 
can be used by a purchaser to purchase the goods and/or 
services; 

receiving a set of multiple accepted payment methods that 
are acceptable to a merchant for the purchase of the 
goods and/or services; and 

deriving an intersection of the sets to yield a common set 
that comprises any available payment methods that are 
both accepted by the merchant and can be used by the 
purchaser for purchase of the goods and/or services. 

54. A system for facilitating electronic purchases of goods 
and/or services, comprising: 

a merchant subsystem resident at a first location and 
having a database that lists merchants in correlation 
with associated sets of accepted payment methods, 
whereby an individual merchant is willing to accept 
any one of the accepted payment methods in that 
merchant's associated set for sale of the goods and/or 
services; 

a subscriber subsystem at the first location and having a 
database that lists subscribers in correlation with asso- 
ciated sets of personal payment methods, whereby an 
individual purchaser could use any one of the personal 
payment methods in that purchaser's associated set to 
- purchase the goods and/or services; and 
a purchase mediator located a second location remote 
from the first location and coupled to receive a set of 
accepted payment methods in the merchant subsystem 
that is associated with a designated merchant and a set 
of personal payment methods in the subscriber sub- 
system that is associated with a requesting subscriber, 
the purchase mediator deriving an intersection of the 
sets to determine a common set that comprises any 
available payment method that is both accepted by the 
designated merchant and is one of the requesting sub- 
scriber's personal payment methods. 

55. A system as recited in claim 54, wherein the purchase 
mediator is a trusted component that has been authenticated 
by a third party certifying authority. 

* * * * * 



07/12/2002, EAST Version: 1.03.0002 



